<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: Software Reuse</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="software_reuse">
<meta name="uma.presentationName" content="Software Reuse">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_vO2uoO0OEduUpsu85bVhiQ"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: Software Reuse</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This guideline describes how to re-use software and design elements.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html" guid="_we3F4ACpEdu8m4dIntu6jA">Abstract Away Complexity</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Analyze the Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/guidances/checklists/architecture_notebook_BC815A4B.html" guid="_17PYUNd6EdmIm-bsRSNCgw">Architecture Notebook</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html" guid="_0fshwMlgEdmt3adZL5Dmdw">Design the Solution</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Evolve the Design</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/tasks/outline_the_arch_FF123A81.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Outline the Architecture</a>
</li>
<li>
<a href="./../../../practice.tech.evolutionary_arch.base/tasks/refine_the_arch_7723A69E.html" guid="_0gRJgMlgEdmt3adZL5Dmdw">Refine the Architecture</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><p>
    Maximizing reuse has always been an important goal of software development. It's better to re-use than to expend the
    cost of creating something new, testing it, and releasing it for the first time with the risk of hidden problems that
    all new software has. Languages, particularly object-oriented ones, have been developed to make reuse easier. But a
    language alone isn't enough to provide cost effective reuse. The bulk of reusable software comes from skilled
    developers and architects who are able to identify and leverage reuse opportunities.
</p>
<h3>
    What is a Reusable Asset?
</h3>
<p>
    The following are some examples of reusable software assets:
</p>
<ul>
    <li>
        Architectural frameworks
    </li>
    <li>
        Architectural mechanisms
    </li>
    <li>
        Architectural decisions
    </li>
    <li>
        Constraints
    </li>
    <li>
        Applications
    </li>
    <li>
        Components
    </li>
    <li>
        COTS software&nbsp;
    </li>
</ul>
<h3>
    Identifying Reuse Opportunities
</h3>
<p>
    There are three perspectives to look at when reusing software: code (implementation), design, and framework or
    architecture.&nbsp; Architects should look to reuse significant application frameworks such as layers that can be
    applied to many different types of applications (for more information, see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>. Developers should look to designs and <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s that can be reused to produce desired behavior or robust structures. They
    should also look at how to reduce the amount of code that needs to be written by leveraging stable components and code
    that has been proven in production environments.
</p>
<p>
    The best way to enable a team to find opportunities for reuse is to exercise excellent design and coding practices.
    It's difficult to find code and design that can be reused when dealing with large classes, classes that don't have a
    clearly defined focus, or classes with relationships that are difficult to understand. Classes should be small, easy to
    understand, and highly cohesive to make it easier to identify reuse opportunities. Any functionality that can be
    reasonably separated into another class should be. Another way of saying this is that any concept that could be applied
    to more than one type of class should be its own class.
</p>
<p>
    For example, if some calculations are added to an existing class, it may make sense to then refactor those calculations
    into a new helper class. Those calculations can&nbsp;then be re-used in any number of other classes without the burden
    of having to know about the functionality of the original class.
</p>
<p>
    The simplest but least efficient way to identify reuse opportunities is to "smell" similar code. A developer may recall
    doing something similar to what they're designing or implementing now. Once the previous implementation has been
    discovered or recalled it can be reused. Developers will always find reuse opportunities this way. But the unstructured
    nature of it won't maximize the potential areas for reuse.
</p>
<p>
    Collaboration is a good technique for identifying reuse opportunities. It provides a structure where identifying reuse
    - instead of writing code - is the goal of the exercise. And the more brains that are looking for reuse opportunities,
    the more likely it is that they'll be found. A brainstorming or review meeting that focuses on identifying reuse
    opportunities would be useful to support this.
</p>
<p>
    Patterns are good ways to find reuse opportunities in designs and frameworks. See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
</p>
<p>
    Analyzing behavior is another good way to identify potential areas for reuse. Analyze how classes need to collaborate
    in order to deliver some specific functionality such as a requirement or feature. This collaboration can be documented
    in sequence (behavior) and class (structure) diagrams and can be reused in similar circumstances.
</p>
<p>
    After looking for similar behavior and returned values, then look for similarity of parameters. If their
    interfaces&nbsp;are not an exact match for the component interfaces being proposed, you can modify the
    proposed&nbsp;signatures to increase the degree of reuse. Some design mechanisms, such as performance or security
    requirements, may disqualify a component from reuse even when there is&nbsp;a perfect match between operation
    signatures.
</p>
<p align="left">
    A common set of components may exist that provides many of the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> that you need&nbsp;for the new system. These components may
    be available either because they were developed or purchased previously for&nbsp;similar systems. Given their
    suitability and compatibility within the software architecture, there may be a need to reverse-engineer these
    components to represent them in a design model and reuse them in a project.
</p>
<p align="left">
    Similar thinking applies to&nbsp;existing databases. Part of the information to be used by the application under
    development may already reside in a database. You may be able to get the classes that represent the database structures
    that hold this information by reverse-engineering the database.
</p>
<p>
    <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> should always be considered when reusing code. Code (or design) is often
    not originally written for re-use, or reusable code may not be a perfect fit for a new situation.
</p>
<h3>
    Assessing and Selecting Assets to Reuse
</h3>
<p>
    To assess and select assets to reuse on your project, you need to understand the requirements of the system's
    environment. You also need to understand the scope and general functionality of the system that the stakeholders
    require. There are several types of assets to consider, including (but not limited to): reference architectures;
    frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&nbsp;repositories (internal or
    external to your organization) and industry literature to identify assets or similar projects.
</p>
<p>
    You need to assess whether available assets contribute to solving the key challenges of the current project and whether
    they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
    between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
    asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
    tradeoffs in adopting it are, in terms of cost, risk, and functionality.
</p>
<p>
    Leverage reuse of existing components by evaluating their interfaces and the behavior that they provide. Reuse
    components when their interfaces are similar or match the interfaces of components you would need to develop from
    scratch. If not similar, modify the newly identified interfaces so you improve the fit with existing components
    interfaces. Work with developers to gain consensus on the suitability of using existing components.
</p>
<p>
    Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
</p>
<h3>
    Reuse Techniques
</h3>
<p>
    Reuse can be performed differently depending on the capabilities of the implementation environment. The simplest
    technique is to copy the code from one place to another. This isn't advisable because it's not really reuse. Multiple
    copies of source code are difficult to maintain and can eventually diverge from each other. Reuse is about using the
    same code to perform similar tasks as a way to increase quality and reduce overhead.
</p>
<p>
    Some languages, such as C++, support templates. Templates, sometimes referred to as parameterized code, are a precursor
    to patterns. Templates are code with parameters that are applied just when the code's needed, at compile time. The C++
    Standard Template Library (STL) is one example. It provides many types of reusable containers (lists, sets, safe
    arrays, etc) that don't have some of the drawbacks of inheritance. Templates such as these are also useful as mix-in
    classes in languages like C++ that support multiple inheritance. Because mix-ins are implemented as templates, they
    allow for a type of multiple inheritance without the baggage.
</p>
<h3>
    Inheritance and Aggregation
</h3>
<p>
    Inheritance (also known as generalization) is an easy way to implement polymorphism and has been used as the primary
    mechanism for reuse in modern object-oriented languages. This is unfortunate, as inheritance imposes a rigid structure
    on the software's design that is difficult to change. Any inheritance hierarchy that shares code from parents to
    children will have problems when it grows to be three or more levels deep. Too many exceptions occur to maintain a pure
    "is-a" relationship between parents and children, where children are always considered to have all the properties and
    behaviors of the parents. Inheritance should be used to share definitions (interfaces), not implementations. Years of
    difficulties with inheriting implementations have made this practice a primary object-oriented design principle.
</p>
<p>
    Whenever inheritance is used, it is best to have only the last child class (leaf node) of the inheritance hierarchy be
    instantiated. All parent classes should be abstract. This is because a class that tries to be both reusable and
    concrete - to provide reusable and specific behavior at the same time - almost always fails to fulfill either goal.
    This is a dimension of cohesiveness. One thing that makes a class cohesive is that it's dedicated to reuse or dedicated
    to a specific implementation, but not both.
</p>
<p>
    Aggregation is a technique that collects or aggregates functionality into larger elements of functionality. It provides
    a structure that's far more flexible and reusable than inheritance. It's better to reuse implementation and design by
    aggregating small pieces of functionality together rather than trying to inherit the functionality from a parent.
</p>
<p>
    You may also find reuse opportunities by reviewing interfaces. If interfaces describe similar behavior it may be
    possible to eliminate one of the interfaces, have just one implementation realize both interfaces, or refactor the
    interfaces to put redundant content in a new, simpler interface.
</p>
<h3>
    Finding Reusable Code
</h3>
<p>
    There are many sources of reusable code beyond what the developers are writing for a specific project. Other places
    from which to harvest code include the following:
</p>
<ul>
    <li>
        Internal (corporate) code libraries
    </li>
    <li>
        Third party libraries
    </li>
    <li>
        Built-in language libraries
    </li>
    <li>
        Code samples from tutorials, examples, books, etc.
    </li>
    <li>
        Local code guru or knowledgeable colleague
    </li>
    <li>
        Existing system code
    </li>
    <li>
        Open source products (be sure to follow any licensing agreements)
    </li>
</ul>
<p>
    Also, many tools that generate code will generate comprehensive code based on minimal specification. For example, a
    design tool might generate the member variable plus a get and a set operation when the designer specifies an attribute.
    Other more sophisticated tools with knowledge of a specific framework can generate voluminous code to ensure that a
    class conforms to the framework. An example of this would be a tool that generates significant additional code when a
    class is marked as a Java entity bean. This sort of consistent transformation from a specification (the design) to an
    implementation (the code) could be considered a form of code reuse as well.
</p>
<h3>
    Don't Reuse Everything
</h3>
<p>
    Reuse makes code and design cheap to use but expensive to build. It requires experience and thoughtful consideration to
    create an implementation or design that's abstract enough for others to re-use, but concrete enough to be truly useful.
    Reusable code must also be maintained. Many organizations have difficulty assigning responsibility for maintaining
    reusable code if they don't have a group dedicated to reuse.
</p>
<p>
    It's usually not a good idea to create code or designs for reuse unless you know it's going to be reused. It's better
    to refactor software to be more reusable after it's discovered that they can be reused. One rule of thumb is to write
    for reuse only when you know you'll use it at least 3 times. Otherwise the cost of building and maintaining that part
    of the software will not be recovered by reduced overhead in other areas of development.
</p></td>
</tr>
</table>
</div>
<div class="sectionHeading">More Information</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Concepts</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>
</li>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Guidelines</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Layering</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
